home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 3755 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  6.7 KB
  1. Path: grafix.xs4all.nl!john.hendrikx
  2. Date: Fri, 23 Feb 96 04:49:48 GMT+1
  3. Newsgroups: comp.sys.amiga.programmer
  4. Distribution: world
  5. Subject: Re: Amiga doesn`t need Pl
  6. MIME-Version: 1.0
  7. Content-Type: text/plain; charset=iso-8859-1
  8. Content-Transfer-Encoding: 8bit
  9. From: john.hendrikx@grafix.xs4all.nl (John Hendrikx)
  10. Message-ID: <john.hendrikx.4gpu@grafix.xs4all.nl>
  11. Organization: Grafix Attack BBS Holland
  12.  
  13. In a message of 20 Feb 96 Juergen "rally" Fischer wrote to All:
  14.  
  15.  >> > JrF> But when it comes to games, I say: AGA is still very usable today
  16.  
  17.  >> >How can you say that?  What do you mean 'games'?  I think your definiti
  18.  
  19.  JrF> DOOM. DESCENT. On a A1200 with megaturbo cpu, it'll run not much slower
  20.  JrF> like on VLB + megaturbo cpu. Just because those games still need some
  21.  JrF> frames even on a megaturbo.
  22.  
  23. You're wrong.  On A1200 with mega-turbo you spend a *FIXED* amount of time
  24. doing 'copying' (C2P).  No matter how fast your CPU is this time is always
  25. there, so if you use a 320x240 screen it will never go faster than a fixed FPS
  26. rate even if your mapping stuff takes 0 cycles.  This gets far worse for
  27. 640x480 screens (which is quite doable on a fast clone).
  28.  
  29. The 'copying' loop simply doesn't exist on the clones, just paste it wherever
  30. you want it in the gfx-buffer and be done with it.  This is likely to be as
  31. fast as a DOOM clone of the A1200 but with the C2P pass disabled (ie, no
  32. display).
  33.  
  34.  >> >games needs adjusting.  What I see on the clones, and the consoles is w
  35.  
  36.  JrF> yep, adjust, the more frames even a megacpu will need, the less
  37.  JrF> important AGA bandwidth becomes!
  38.  
  39. You're thinking the wrong way, with megacpu you are actually likely to use LESS
  40. frames, so the more important AGA bandwidth becomes.  Or maybe you didn't
  41. notice that with TextDemo the time needed for C2P goes UP relatively on faster
  42. CPU's?
  43.  
  44.  >> >call games.  Not the AGA crap we have to put up with.
  45.  
  46.  JrF> You rely on _programming crap_ in combination with low cpu.
  47.  
  48. No, a game which is unplayable because it uses a fuzzy 2x2 160x120 display (or
  49. less!) and jerks like hell is CRAP.
  50.  
  51.  JrF> 99% of all games are coded to crappy to see AGA bandwidth as  real
  52.  JrF> limit!
  53.  
  54. There are limits to what a programmer will do to speed up his game.  Tricks
  55. like Blitter assistance, BlitterScreen, Chunky Copper and so on all are
  56. incredibly hard to implement or distort the display or limit your game in some
  57. way:
  58.  
  59.  Blitter assistance: Requires non-interleaved bitmaps, impossible to
  60.                      C2P a smaller part of the whole screen
  61.                      (horizontally), it's effectiveness depends heavily
  62.                      on factors like CPU, fast-memory, etcetera...
  63.  
  64.                      Try to get it to work on Intuition-screen and make
  65.                      your DOOM-clone support multiple window sizes.
  66.  
  67.       Chunky Copper: Crappy resolution, wastes lots of ChipRAM bandwidth
  68.                      (copper and bitplane DMA fully loaded), pixels
  69.                      are written 1 word at the time.
  70.  
  71.       BlitterScreen: Problems similair to Blitter assistance, but
  72.                      additionally you will need to turn up the contrast
  73.                      on your monitor, because the result of masking out
  74.                      every 2nd pixel effectively means all pixels are
  75.                      twice as dark as they should be with a real 2x1
  76.                      display.
  77.  
  78. Any idea of how much C2P routines you could end up with when your game is done?
  79.  
  80.  Blitter+CPU C2P optimized for A1200 specifically
  81.  Blitter+CPU C2P optimized for 16-bit ChipRAM machines (ECS)
  82.  Blitter+CPU C2P optimized for 030 32-bit ChipRAM machines (4000/030)
  83.  CPU C2P optimized for 040 16-bit ChipRAM machines (ECS + 040)
  84.  CPU C2P optimized for 040 32-bit ChipRAM machines (4000/040)
  85.  
  86. and probably one which uses AKIKO, and of course for each of these routines a
  87. version which does 2x1 displays, and versions for 16, 64 and 256 colors. Maybe
  88. also add ChunkyCopper and BlitterScreen C2P?  It looks like we've gone C2P
  89. crazy...
  90.  
  91. On top of that you will also want to support gfx-cards... and you need to write
  92. the rest of the game as well (but that's just a small part compared to all
  93. those C2P routines).  Have we reached the programmer's limit yet?
  94.  
  95.  >> Agreed.   AGA  is  *really* crap.  Who cares if we can C2P a 2x2 screen
  96.  >> faster than a below-average gfx-card, when the PC's are running 640*480
  97.  >> fully texturemapped/shaded games in two frames.
  98.  
  99.  JrF> In two frames ? You must rely on a P133 system, with very good board &
  100.  JrF> mem! If you can afford an Amiga which got same power, you surely can
  101.  JrF> afford a gfx card, too.
  102.  
  103. There is no Amiga with the same power as the P133.  And my 'average' (and 2
  104. year old $100) VLB Gfx card handles 15 MB/sec easily, more than enough to do
  105. 640x480 in 2 frames.
  106.  
  107.  >> > JrF> Later AGA+ having 10 planes etc, would be a nice thing, yes.
  108.  
  109.  >> >Please not, 10 planes would be fucking slow.  For me planar maxes 
  110.  
  111.  JrF> 10bit is for example faster than 16bit, for your information.
  112.  
  113. At what?  I bet it is slower than 16-bit for anything CPU calculated (ie,
  114. gouraud polygons, tmapping, rotating, and so on).
  115.  
  116.  >> >You forget that you still need a 68040 atleast to do DOOM even if you h
  117.  >> >super-fast Chunky card.  That's why there is no clone, the C2P problem 
  118.  
  119.  JrF> huh logic ? There is no clone because nobody programed it. A clone is
  120.  JrF> software, exisiting independent from the fact if a 040 exists.
  121.  
  122. There is no (good) clone because it requires a 040 + fast Chunky gfx-card,
  123. period.  Caused of course by the fact that 040 + fast Chunky gfx-card is a rare
  124. combination found in the Amiga world.
  125.  
  126.  >> >makes it worse though, on Amiga you'd require a 68060 to do fast DOOM (
  127.  
  128.  JrF> the C2P problem on 040 is a PCer myth! C2P doesn't make it worse.
  129.  
  130. Yes it does, see TextDemo.  The percentage of CPU time used for the C2P is
  131. NON-EXISTANT on the clones, because the 'fast-ram buffer' we use on Amiga is
  132. called 'the screen' on the clones.  No extra copying (or converting for that
  133. matter) needed.
  134.  
  135.  >> >runs only 15-20 FPS on a 68060/50, 320x240x8 1x1, floors, walls, ceilin
  136.  >> >depressing).
  137.  JrF> huh ? first you tell me there is no clone and then you tell  YOU know
  138.  JrF> about how much it'll run on a 060 ? logic ?
  139.  
  140. That's TextDemo 5.7x (unreleased version) someone tested for me.  15-20 FPS for
  141. a 68060/50 which is supposed to be 2-3 times as powerfull as a 486DX2/50 is
  142. quite depressing, considering that that 486 will do it at 30 FPS.  Now just
  143. translate that to the slower Amiga's (ie, the ones only equipped with 030's and
  144. 040's).
  145.  
  146. Grtz John
  147.  
  148. -----------------------------------------------------------------------
  149.  John.Hendrikx@grafix.xs4all.nl   TextDemo/FastView/Etc... development
  150. -----------------------------------------------------------------------
  151. -- Via Xenolink 1.985B5, XenolinkUUCP 1.1
  152.